Efficiency of Extended Static Checkers

Most research in computer science, software engineering, formal methods, and perhaps a few other programming-related disciplines contributes techniques and ideas that improve the quality of software. The quality has two faces. A program is good if it does what the programmers intended. A program is really good if it does what its users want. The problem of making programmers’ intentions agree with the users’ requirements will be neatly covered under the rug in what follows. Rest assured, there are many qualified people working on it. So let us shift the focus towards making programs agree with programmers. For sure, no programmer wants their editor to change the selected region after a search and replace operation, or to suddenly display a blue screen and stop react to user input. These disagreements between the program and the programmer are commonly called bugs. An empirical study [CAHM04] of active open source projects revealed that the average number of bugs per project is 509 and the median is 279. Moreover, projects with many downloads tend to also have many developers, many bug reports, and low bug-fixing time. It is not clear how these numbers should be interpreted, but I believe they do show that programs have bugs. They also show that bugs should be fixed early. Extrapolating, it seems a good idea to fix bugs before they reach the users. Many programming tools, including compilers, are actively pointing to possible trouble spots. Programmers are actively looking for bugs too. Yet, bugs still reach users in high numbers. It is quite unlikely that one idea or technique that decisively impacts the number of bugs released to users will be found [FPB95]. Instead, the constant stream of research output, together with advocacy and teaching, will steadily raise the bar. Even if this is the most likely future evolution, most people, including researchers, can’t stop to have personal favorite techniques. My current favorite is extended static checking [BLS04]. And, judg-